.
\enableexperiments[fonts.compact]
\definefontfamily[mainface][rm][TeX Gyre Termes]
[it={style:regular, features:{default,slanted}},
sl={style:regular, features:{default,slanted}}]
\setupbodyfont[mainface]
\starttext
\startstyle[style=italic]normal {\em emphasized} normal\stopstyle
\stoptext
[mainface][rm][TeX Gyre Termes]
[it={style:regular, features:{default,slanted}},
sl={style:regular, features:{default,slanted}}]
\setupbodyfont[mainface]
\starttext
\startstyle[style=italic]normal {\em emphasized} normal\stopstyle
\stoptext
The only way to mask the effect is to create a new
umulate, like
> [...]
> which you will now wikify...
Many thanks for your reply, Hans.
I will wikify this, once I figure out where it can fit in the wiki (in
due time, since ConTeXt is more and more complex for me lately and my
free time is less and less these days).
I only used \enableexpe
On 3/10/2024 9:32 AM, Pablo Rodriguez via ntg-context wrote:
On 3/9/24 16:04, Wolfgang Schuster wrote:
Pablo Rodriguez via ntg-context schrieb am 08.03.2024 um 19:39:
[...]
\enableexperiments[fonts.compact]
Which seeems weird to me. Or at least, I thought I read that Hans
enabled it by
On 3/9/24 16:04, Wolfgang Schuster wrote:
> Pablo Rodriguez via ntg-context schrieb am 08.03.2024 um 19:39:
>> [...]
>>\enableexperiments[fonts.compact]
>>
>> Which seeems weird to me. Or at least, I thought I read that Hans
>> enabled it by default in LMTX.
>
> AFAIR Hans uses the setting in
Pablo Rodriguez via ntg-context schrieb am 08.03.2024 um 19:39:
On 3/8/24 19:09, Wolfgang Schuster wrote:
Pablo Rodriguez via ntg-context schrieb am 08.03.2024 um 18:50:
[...]
LMTX gets b, c and d in slanted form.
LuaTeX gets only b and c in slanted form.
[...]
I get b and d in italic which
On 3/8/24 19:09, Wolfgang Schuster wrote:
> Pablo Rodriguez via ntg-context schrieb am 08.03.2024 um 18:50:
>> [...]
>> LMTX gets b, c and d in slanted form.
>>
>> LuaTeX gets only b and c in slanted form.
> [...]
> I get b and d in italic which is the expected output.
Sorry, my LuaTeX is getting
},
it={style: regular, features:{default, quality, slanted}},
sl={style: regular, features:{default, quality, slanted}}]
\setupbodyfontenvironment
[default]
[em=italic]
\setupbodyfont[mainface]
\starttext
\startTEXpage[offset=1em]
a\\
\em b\\
\em c\\
\em d
},
it={style: regular, features:{default, quality, slanted}},
sl={style: regular, features:{default, quality, slanted}}]
\setupbodyfontenvironment
[default]
[em=italic]
\setupbodyfont[mainface]
\starttext
\startTEXpage[offset=1em]
a\\
\em b\\
\em c\\
\em d
: regular, features:{default, quality, slanted}}]
\setupbodyfontenvironment
[default]
[em=italic]
\setupbodyfont[mainface]
\starttext
\startTEXpage[offset=1em]
a\\
\em b\\
\em c\\
\em d\\
\stopTEXpage
\stoptext
LMTX gets b, c and d in slanted form.
LuaTeX gets only
Mikael, Wolfgang:
This is in reference to the prior
Re: redefine space to be the same as \␣ similar to knuthian approach
> Maybe your system is broken?
>
> >
> > > 2. The example below results in a correct output for \TEX.
> > >
> >
> > Not in my end with any font other than latin modern
>
On Fri, 01 Mar 2019 11:17:56 +0100 Hans Hagen wrote
> On 2/28/2019 12:38 PM, Marcel Krger wrote:
> > On 2/23/2019 1:50 PM, Ulrike Fischer wrote:
> >> As reported on the dev-luatex list --- is converted to an en-dash
> >> (instead of em-dash) if
On 3/1/2019 1:15 PM, Ulrike Fischer wrote:
TeXLive is frozen and pretest has begun, so I don't see a danger to
apply patches now.
binaries get frozen at 22/3 and context isn't checked in yet (comes
after first binary generation)
anyway, i'll look at it (maybe this weekend)
Hans
Am Fri, 1 Mar 2019 11:17:56 +0100 schrieb Hans Hagen:
> it looks ok in context
You need to set automatichyphenmode=0 to see the problem in context:
the handling of the --- ligature is clearly broken in some cases:
\starttext
\automatichyphenmode=0
A---B A --- B
\stoptext
> Hm, I don't see
sh
> >> (instead of em-dash) if there are no spaces around the ---.
> >>
> >> We could now reproduce the problem also with the generic fontloader:
> >> it appears only with mode=node. I'm using the files from 2019-02-14,
> >> but the problem ap
On 2/28/2019 12:38 PM, Marcel Krüger wrote:
On 2/23/2019 1:50 PM, Ulrike Fischer wrote:
As reported on the dev-luatex list --- is converted to an en-dash
(instead of em-dash) if there are no spaces around the ---.
We could now reproduce the problem also with the generic fontloader:
it appears
On 2/23/2019 1:50 PM, Ulrike Fischer wrote:
> As reported on the dev-luatex list --- is converted to an en-dash
> (instead of em-dash) if there are no spaces around the ---.
>
> We could now reproduce the problem also with the generic fontloader:
> it appears only with mode=
is not so large and when my eyes
tire. If -- wouldn't work I would resort to a command like \ndash
instead only to get a better visual clue what's in the document.
But regardless from the input method. How can one enable a line
break after an em-dash when \automichyphenmode is 1? The only way I
found
itor, even more if the screen is not so large and when my eyes
> tire. If -- wouldn't work I would resort to a command like \ndash
> instead only to get a better visual clue what's in the document.
>
> But regardless from the input method. How can one enable a line
> break after an e
itor, even more if the screen is not so large and when my eyes
> tire. If -- wouldn't work I would resort to a command like \ndash
> instead only to get a better visual clue what's in the document.
>
> But regardless from the input method. How can one enable a line
> break after an e
would resort to a command like \ndash
instead only to get a better visual clue what's in the document.
But regardless from the input method. How can one enable a line
break after an em-dash when \automichyphenmode is 1? The only way I
found is to explicitly insert a penalty:
\starttext
\hsize=2pt
dash
On 2/23/2019 4:30 PM, Ulrike Fischer wrote:
Am Sat, 23 Feb 2019 15:55:53 +0100 schrieb Hans Hagen:
As reported on the dev-luatex list --- is converted to an en-dash
(instead of em-dash) if there are no spaces around the ---.
in context we set:
\automatichyphenmode=1
This solves
Am Sat, 23 Feb 2019 15:55:53 +0100 schrieb Hans Hagen:
>> As reported on the dev-luatex list --- is converted to an en-dash
>> (instead of em-dash) if there are no spaces around the ---.
> in context we set:
> \automatichyphenmode=1
This solves the problem and after s
On 2/23/2019 1:50 PM, Ulrike Fischer wrote:
As reported on the dev-luatex list --- is converted to an en-dash
(instead of em-dash) if there are no spaces around the ---.
We could now reproduce the problem also with the generic fontloader:
it appears only with mode=node. I'm using the files from
As reported on the dev-luatex list --- is converted to an en-dash
(instead of em-dash) if there are no spaces around the ---.
We could now reproduce the problem also with the generic fontloader:
it appears only with mode=node. I'm using the files from 2019-02-14,
but the problem appeared first
On 5/15/2017 8:27 PM, Pablo Rodriguez wrote:
On 05/15/2017 03:52 PM, Hans Hagen wrote:
On 5/14/2017 8:21 PM, Pablo Rodriguez wrote:
[...]
Select all, copy and paste it on a pure-text editor. You will get two
and four hyphens for en and em dashes, respectively.
Could you confirm this? Until
On 05/15/2017 03:52 PM, Hans Hagen wrote:
> On 5/14/2017 8:21 PM, Pablo Rodriguez wrote:
>> [...]
>> Select all, copy and paste it on a pure-text editor. You will get two
>> and four hyphens for en and em dashes, respectively.
>>
>> Could you confirm this? Until
]
-- ---
– —
\stopTEXpage
\stoptext
Select all, copy and paste it on a pure-text editor. You will get two
and four hyphens for en and em dashes, respectively.
Could you confirm this? Until very recently, I copied en and em dashes
from PDF documents generated by ConTeXt.
it has to do with more aggressive
from the generated document (it also happens with
> your attached PDF file):
>
> \starttext
> \startTEXpage[offset=1em]
> -- ---
>
> – —
> \stopTEXpage
> \stoptext
>
> Select all, copy and paste it on a pure-text editor. You will get two
> and four
topTEXpage
\stoptext
Select all, copy and paste it on a pure-text editor. You will get two
and four hyphens for en and em dashes, respectively.
Could you confirm this? Until very recently, I copied en and em dashes
from PDF documents generated by ConTeXt.
Many thanks for your help,
Pablo
I confirm the issue in NOT present in my machine (Arch Linux x64). I can
see the dashes as they are supposed to be.
Andrés Conrado Montoya
http://chiquitico.org
___
If your question is of interest to others as well,
It works flawless in arch linux 64bits.
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage
On Thu, May 11, 2017 at 9:04 PM, Pablo Rodriguez <oi...@gmx.es> wrote:
> On 05/11/2017 04:17 PM, Thomas Floeren wrote:
>>> On 9. May 2017, at 21:10, Pablo Rodriguez wrote:
>>> [...]
>>> Ligatures aren’t converted and even real en and em dashes are converted
On 05/11/2017 04:17 PM, Thomas Floeren wrote:
>> On 9. May 2017, at 21:10, Pablo Rodriguez wrote:
>> [...]
>> Ligatures aren’t converted and even real en and em dashes are converted
>> to hyphens.
>>
>> Could anyone confirm the issue?
>
> Works as expect
EXpage
>\stoptext
>
> I get as result:
>
>--
>--
>
> Ligatures aren’t converted and even real en and em dashes are converted
> to hyphens.
>
> Could anyone confirm the issue?
Works as expected here, with ConTeXt 2017.05.10 10:41
Best,
T
Dear list,
using latest beta from 2017.05.09 10:14 with the following sample:
\starttext
\startTEXpage[offset=1em]
-- ---
– —
\stopTEXpage
\stoptext
I get as result:
--
--
Ligatures aren’t converted and even real en and em dashes are converted
On 3/31/2017 11:52 AM, Marco Patzer wrote:
On Fri, 31 Mar 2017 11:46:00 +0300
Kostirya <kosti...@gmail.com> wrote:
Two hyphens do not replaced on em—dash when dejavu,14pt
Use the tlig font feature
\definefontfeature
[tlig]
[default]
[tlig=yes]
\definefontfeature
[d
:00 +0300
> Kostirya <kosti...@gmail.com> wrote:
>
>> Two hyphens do not replaced on em—dash when dejavu,14pt
>
> Use the tlig font feature
>
> \definefontfeature
> [tlig]
> [default]
> [tlig=yes]
>
> Marco
>
On Fri, 31 Mar 2017 11:46:00 +0300
Kostirya <kosti...@gmail.com> wrote:
> Two hyphens do not replaced on em—dash when dejavu,14pt
Use the tlig font feature
\definefontfeature
[tlig]
[default]
[tlig=ye
l.com>:
>> Hello.
>> Two hyphens do not replaced on em—dash when dejavu,14pt
>> :-(
>>
>>
>>
>> \starttext
>> 1-2 11--22
>>
>> \switchtobodyfont[dejavu,14pt]
>> 1-2 11--22
>>
>> \stoptext
I apologize.
It is not hyphen symbol. It is unicode.
Everything is working!
2017-03-31 11:46 GMT+03:00 Kostirya <kosti...@gmail.com>:
> Hello.
> Two hyphens do not replaced on em—dash when dejavu,14pt
> :-(
>
>
>
> \starttext
> 1-2 11--22
>
> \switch
Hello.
Two hyphens do not replaced on em—dash when dejavu,14pt
:-(
\starttext
1-2 11--22
\switchtobodyfont[dejavu,14pt]
1-2 11--22
\stoptext
___
If your question is of interest to others as well, please add
On 12/20/2015 5:06 PM, Pablo Rodriguez wrote:
Dear list,
after upgrading to beta from 2015.12.20 00:29, I don’t get dashes in the
following sample:
\starttext
\startTEXpage[offset=1em]
en--dash: --\\
em---dash: ---
\stopTEXpage
\stoptext
It worked fine with beta
Dear list,
after upgrading to beta from 2015.12.20 00:29, I don’t get dashes in the
following sample:
\starttext
\startTEXpage[offset=1em]
en--dash: --\\
em---dash: ---
\stopTEXpage
\stoptext
It worked fine with beta from 2015.11.19 19:13.
I’m afraid this may be a bug
On 07/14/2015 07:11 PM, Hans Hagen wrote:
On 7/14/2015 3:42 PM, Pablo Rodriguez wrote:
Hans,
checking beta from 2015.07.12 23:30 in Win7 64bit works fine (ligatures,
no ligatures and dashes) with newotf.
But I’m afraid that beta from 2015.07.14 10:37 doesn’t work disabling
ligatures and
that this sample doesn’t work with latest beta either:
\usemodule[newotf]
\definefontfeature[noliga][liga=no]
\starttext
\startTEXpage[offset=1em]
fiflff no--liga:
\addfeature[noliga]fiflff
--- em--dash
\stopTEXpage
\stoptext
I may be wrong, but I
On 07/14/2015 12:54 PM, Rik Kabel wrote:
On 2015-07-12 12:52, Hans Hagen wrote:
[...]
i just checked the distribution on a vm and it works ok so best first
figure out why the tex ligs don't show up (when that relevant file is
not loaded well other overloads might also fail so that can be
On 7/14/2015 3:42 PM, Pablo Rodriguez wrote:
On 07/14/2015 12:54 PM, Rik Kabel wrote:
On 2015-07-12 12:52, Hans Hagen wrote:
[...]
i just checked the distribution on a vm and it works ok so best first
figure out why the tex ligs don't show up (when that relevant file is
not loaded well other
=no]
\starttext
\startTEXpage[offset=1em]
fiflff no--liga:
\addfeature[noliga]fiflff
--- em--dash
\stopTEXpage
\stoptext
I may be wrong, but I think that the non-deactivated OpenType feature is
related to the non-activated em- and en-dashes.
To the list members: could you test
On 07/12/2015 11:33 AM, Hans Hagen wrote:
On 7/12/2015 6:55 AM, Pablo Rodriguez wrote:
[...]
May the different behaviour caused by the fact that you use
LuaTeX-0.80.1 (as displayed in
http://www.pragma-ade.com/general/qrcs/setup-en.pdf) and we have
LuaTeX-0.80?
i can't imagine .. can you
On 7/12/2015 6:55 AM, Pablo Rodriguez wrote:
On 07/11/2015 11:55 PM, Rik Kabel wrote:
On 2015-07-11 17:30, Hans Hagen wrote:
On 7/11/2015 5:09 PM, Pablo Rodriguez wrote:
Hans,
[...]
I discovered that em- and en-dashes aren’t enabled by default.
Is this intended?
works ok here
Hmmm. Fails
On 7/12/2015 12:49 PM, Pablo Rodriguez wrote:
On 07/12/2015 11:33 AM, Hans Hagen wrote:
On 7/12/2015 6:55 AM, Pablo Rodriguez wrote:
[...]
May the different behaviour caused by the fact that you use
LuaTeX-0.80.1 (as displayed in
http://www.pragma-ade.com/general/qrcs/setup-en.pdf) and we have
On 7/12/2015 5:27 PM, Pablo Rodriguez wrote:
On 07/12/2015 05:17 PM, Otared Kavian wrote:
Hi Pablo,
On my installation everything seems to work fine: Context
version 2015.07.12 15:40
Hi Otared,
many thanks for your reply.
Which is your OS and architecture?
you use m-newotf from the
:
\usemodule[newotf]
\definefontfeature[noliga][liga=no]
\starttext
\startTEXpage[offset=1em]
fiflff no--liga:
\addfeature[noliga]fiflff
--- em--dash
\stopTEXpage
\stoptext
I may be wrong, but I think that the non-deactivated OpenType feature is
related
]
\definefontfeature[noliga][liga=no]
\starttext
\startTEXpage[offset=1em]
fiflff no--liga:
\addfeature[noliga]fiflff
--- em--dash
\stopTEXpage
\stoptext
I may be wrong, but I think that the non-deactivated OpenType feature is
related to the non-activated em
beta either:
\usemodule[newotf]
\definefontfeature[noliga][liga=no]
\starttext
\startTEXpage[offset=1em]
fiflff no--liga:
\addfeature[noliga]fiflff
--- em--dash
\stopTEXpage
\stoptext
I may be wrong, but I think that the non-deactivated OpenType
no--liga: \addfeature[noliga]fiflff --- em--dash \stopTEXpage \stoptextI may be wrong, but I think that the non-deactivated OpenType feature isrelated to the non-activated em- and en-dashes.To the list members: could you test the sample above and tell em- anden-dashes work and if no-liga disables
On 07/12/2015 05:04 PM, Axel Kielhorn wrote:
Am 12.07.2015 um 16:38 schrieb Pablo Rodriguez:
[...]
To the list members: could you test the sample above and tell em- and
en-dashes work and if no-liga disables ligatures? Adding architecture
may help.
I’m using
current version: 2015.07.12
On 07/12/2015 05:57 PM, Hans Hagen wrote:
On 7/12/2015 5:27 PM, Pablo Rodriguez wrote:
[...]
Hi Otared,
many thanks for your reply.
Which is your OS and architecture?
you use m-newotf from the distribution?
I use the one installed after updating the beta.
I have just checked it and it
On 07/12/2015 05:17 PM, Otared Kavian wrote:
Hi Pablo,
On my installation everything seems to work fine: Context
version 2015.07.12 15:40
Hi Otared,
many thanks for your reply.
Which is your OS and architecture?
Many thanks again,
Pablo
--
http://www.ousia.tk
Hans,
with the following sample:
\usemodule[newotf]
%~ \setupbodyfont
%~ [palatino]
\starttext
--- em--dash (with en--dash inside)
\stoptext
I discovered that em- and en-dashes aren’t enabled by default.
Is this intended?
Many thanks for your help,
Pablo
On 7/11/2015 5:09 PM, Pablo Rodriguez wrote:
Hans,
with the following sample:
\usemodule[newotf]
%~ \setupbodyfont
%~ [palatino]
\starttext
--- em--dash (with en--dash inside)
\stoptext
I discovered that em- and en-dashes aren’t enabled by default
On 2015-07-11 17:30, Hans Hagen wrote:
On 7/11/2015 5:09 PM, Pablo Rodriguez wrote:
Hans,
with the following sample:
\usemodule[newotf]
%~ \setupbodyfont
%~ [palatino]
\starttext
--- em--dash (with en--dash inside)
\stoptext
I discovered that em- and en
On 07/11/2015 11:55 PM, Rik Kabel wrote:
On 2015-07-11 17:30, Hans Hagen wrote:
On 7/11/2015 5:09 PM, Pablo Rodriguez wrote:
Hans,
[...]
I discovered that em- and en-dashes aren’t enabled by default.
Is this intended?
works ok here
Hmmm. Fails here with newotf, works without. Context
How about
Most newspapers ||and all that follow AP style|| insert a space
before and after the em dash.
Might I suggest that this could/should be set|-|up in Polish to repeat
the (second) emdash if it is followed by a line break?
Alan
On Mon, 2 Mar 2015 10:02:53 +0100
Hans Hagen pra
On 3/1/2015 8:34 PM, Piotr Kopszak wrote:
Many Thanks Hans!
But that's not exactly what I need, sorry for being imprecise, I do
not need to repeat hyphens, but only em dashes (or en dashes, which
ever are used in the document) in situations like this.
Most newspapers — and all that follow AP
Many Thanks Hans!
But that's not exactly what I need, sorry for being imprecise, I do
not need to repeat hyphens, but only em dashes (or en dashes, which
ever are used in the document) in situations like this.
Most newspapers — and all that follow AP style — insert a space before
and after
Hello list,
This is probably a Polish idiosyncrasy, but we have to live with it.
According to punctuation rules when an em dash is at the end of a
line, it should be repeated at the beginning of the next one (true, it
is often disregarded due to lack of support for it in typesetting
programs
On 3/1/2015 5:41 PM, Piotr Kopszak wrote:
Hello list,
This is probably a Polish idiosyncrasy, but we have to live with it.
According to punctuation rules when an em dash is at the end of a
line, it should be repeated at the beginning of the next one (true, it
is often disregarded due to lack
Hopefully, this is the correct list for this question. I'm trying to typeset
documents using the font Hoefler on MacOSX (10.8.4) with ConTeXt 2013.05.28
from the TeXlive 2013 distribution. All works, but unfortunately, em dashes
are not typeset correctly; there are three dashes instead
On 2013–08–19 Martin Moncrieffe wrote:
Hopefully, this is the correct list for this question. I'm trying
to typeset documents using the font Hoefler on MacOSX (10.8.4)
with ConTeXt 2013.05.28 from the TeXlive 2013 distribution. All
works, but unfortunately, em dashes are not typeset
, but unfortunately, em dashes are not typeset correctly;
there are three dashes instead of a continuous line.
The font (at least my version) does not contain an em dash in slot
U+2014.
I checked a different version of the font (1.000) and it works. It
seems you're using a version not containing an em
2013.05.28 from the TeXlive 2013 distribution. All
works, but unfortunately, em dashes are not typeset correctly;
there are three dashes instead of a continuous line.
The font (at least my version) does not contain an em dash in slot
U+2014.
I checked a different version of the font (1.000
Hi Marko,
On 20 Aug 2013, at 10:52, Marco Patzer li...@homerow.info wrote:
I checked a different version of the font (1.000) and it works. It
seems you're using a version not containing an em dash.
Thanks for looking into this. Finder reports that my version of Hoefler is
8.0d2e1
On 2013–08–20 Martin Moncrieffe wrote:
Finder reports that my version of Hoefler is 8.0d2e1.
This means we already have three different Hoefler versions in this
thread.
[…] shows the the em dash is present in the font.
When I use a version with em dash, your example works here. Someone
using
Hoefler on MacOSX (10.8.4)
with ConTeXt 2013.05.28 from the TeXlive 2013 distribution. All
works, but unfortunately, em dashes are not typeset correctly;
there are three dashes instead of a continuous line.
The font (at least my version) does not contain an em dash in slot
U+2014.
I checked
I don't think it's the font. I have been trying to produce an em dash
using the latest stable release from contextgarden.net, with a couple
of different fonts--Alegreya, which is a free OpenType font, Latin
Modern, and one other that I don't remember. In my case, regardless of
the font, \emdash
Hi Matt,
On 20 Aug 2013, at 13:00, Matt Gushee m...@gushee.net wrote:
I don't think it's the font. I have been trying to produce an em dash
using the latest stable release from contextgarden.net, with a couple
of different fonts--Alegreya, which is a free OpenType font, Latin
Modern, and one
On 8/20/2013 2:07 PM, Martin Moncrieffe wrote:
Hi Matt,
On 20 Aug 2013, at 13:00, Matt Gushee m...@gushee.net
mailto:m...@gushee.net wrote:
I don't think it's the font. I have been trying to produce an em dash
using the latest stable release from contextgarden.net
http://contextgarden.net
On Tue, Aug 20, 2013 at 02:00:16PM +0200, Hans Hagen wrote:
great ... another non standard use of names
There are no standard glyph names for TrueType/OpenType fonts. AGL is
completely optional, and is not part of any standard. Fonts can, and do,
use names that does not follow AGL (or no names
My main font is Japanese and I'm falling back on a different font for
Latin characters.
The \it switch works fine, but \em renders the Japanese font (e.g. page
numbers in the index). Is there a way to have \em use the italic (of the
fallback font)?
Thanks,
Severin
Am 02.04.2012 um 11:37 schrieb S Barmeier:
My main font is Japanese and I'm falling back on a different font for
Latin characters.
The \it switch works fine, but \em renders the Japanese font (e.g. page
numbers in the index). Is there a way to have \em use the italic (of the
fallback font
On 04/02/2012 09:18 PM, Wolfgang Schuster wrote:
Am 02.04.2012 um 11:37 schrieb S Barmeier:
My main font is Japanese and I'm falling back on a different font for
Latin characters.
The \it switch works fine, but \em renders the Japanese font (e.g. page
numbers in the index
Am 02.04.2012 um 15:10 schrieb S Barmeier:
On 04/02/2012 09:18 PM, Wolfgang Schuster wrote:
Am 02.04.2012 um 11:37 schrieb S Barmeier:
My main font is Japanese and I'm falling back on a different font for
Latin characters.
The \it switch works fine, but \em renders the Japanese font
I discovered this by hunting through font-ini.mkii:
\setupbodyfontenvironment [default] [em={\slanted\color[red]}]
Seems to work well. You see, I want to use the same ConTeXt files for two
purposes: to create a set of printable notes (without colour) and to make a
set of displayable onscreen
Am 21.02.2012 um 10:19 schrieb Alasdair McAndrew:
I discovered this by hunting through font-ini.mkii:
\setupbodyfontenvironment [default] [em={\slanted\color[red]}]
Better \setupbodyfontenvironment[default][em={\sl\red}].
Seems to work well. You see, I want to use the same ConTeXt files
Am 21.02.2012 um 13:05 schrieb Wolfgang Schuster:
Am 21.02.2012 um 10:19 schrieb Alasdair McAndrew:
I discovered this by hunting through font-ini.mkii:
\setupbodyfontenvironment [default] [em={\slanted\color[red]}]
Better \setupbodyfontenvironment[default][em={\sl\red}].
I was too
In some overheads I'm creating, I'd like emphasized text {\em like this} to
appear as red. I hoped that something like this would work:
\setupbodyfontenvironment[default][em={slanted, textcolor=red}]
but it doesn't. What is the canonical way of obtaining red, emphasized,
text?
Thanks
On Tue, 21 Feb 2012, Alasdair McAndrew wrote:
In some overheads I'm creating, I'd like emphasized text {\em like this} to
appear as red. I hoped that something like this would work:
\setupbodyfontenvironment[default][em={slanted, textcolor=red}]
but it doesn't. What is the canonical way
On 16-12-2011 00:31, Chris Lott wrote:
I found a bunch of code that sets up Minion Pro (and Myriad) typefaces that
seems to work (once I modified MinionPro-Italic and the rest to be MinionPro-It
as it is on my system:
http://pastebin.com/muSg4dZN
However, neither \em nor \slanted make any
I found a bunch of code that sets up Minion Pro (and Myriad) typefaces that
seems to work (once I modified MinionPro-Italic and the rest to be MinionPro-It
as it is on my system:
http://pastebin.com/muSg4dZN
However, neither \em nor \slanted make any change to the text. Since I'm
basically
Until now I always used a - (minus sign) to define a sub sentence or for an
optional word, like:
This is -now- not necessary,
I understood that normally you use the em dash for this. But for only a
word, this seems a little big. Could I then use an en dash or should I keep
using a minus sign
Am Mon, 21 Mar 2011 10:51:44 +0100 schrieb Cecil Westerhof:
Until now I always used a - (minus sign) to define a sub sentence or for an
optional word, like:
This is -now- not necessary,
I understood that normally you use the em dash for this. But for only a
word, this seems a little
2011/3/21 Ulrike Fischer ne...@nililand.de
Am Mon, 21 Mar 2011 10:51:44 +0100 schrieb Cecil Westerhof:
Until now I always used a - (minus sign) to define a sub sentence or for
an
optional word, like:
This is -now- not necessary,
I understood that normally you use the em dash
.
{\em This empathized text starting a new paragraph} should not
scratch the picture left.
When some text contains {\em an empathized text inside the
paragraph}, text flows normally as expected.
\input tufte
\stoptext
---
You can add a \strut in front of {\em - that’s a usual workaround
with some text enclosed into {\em ...} group inside the
free area formed (affected) by \placefigure.
---
\starttext
\placefigure
[left,none]
{}
{ \startMPcode
draw (0,0)--(6cm,6cm);
\stopMPcode
}
This is a normal text -- it flows around the picture on the left
Am 25.02.2011 um 09:16 schrieb Henning Hraban Ramm:
You can add a \strut in front of {\em - that’s a usual workaround for
problems with non-letters starting a paragraph.
The usual workaround is \dontleavehmode.
Wolfgang
wrote:
Am 25.02.2011 um 09:16 schrieb Henning Hraban Ramm:
You can add a \strut in front of {\em - that’s a usual workaround for problems
with non-letters starting a paragraph.
The usual workaround is \dontleavehmode.
Wolfgang
--
Ing. Lukáš Procházka [mailto:l...@pontex.cz]
Pontex s. r. o
problem.
I wonder why the behaviour described bellow occurs and how to typeset a
paragraph starting with some text enclosed into {\em ...} group inside the
free area formed (affected) by \placefigure.
---
\starttext
\placefigure
[left,none]
{}
{ \startMPcode
draw (0,0
On 25-2-2011 9:44, Procházka Lukáš Ing. - Pontex s. r. o. wrote:
... Thanks for the answers.
I'm familiar with using \dontleavehmode when needing to keep a figure
midaligned; I had no idea that this would be a similar situation (and
solution).
{\em xxx ..}
the first x triggers the start
1 - 100 of 144 matches
Mail list logo
